Thanks, but this isn't the right fix.

The change makes the top-level-vs-dependency classification depend on --last-failed, which conflates a project's structural role with test filtering. It also duplicates the post-shard filter (the same postShardTestFilters predicate then runs again a few lines below), and it regresses dependency semantics: when a top-level project has no matching tests but one of its setup/dependency projects does, that setup project gets promoted to top-level and run filtered/standalone instead of in full as a prerequisite.

The root cause is that dependency projects are pruned before post-shard filters are applied — the fix belongs there, not in the top-level predicate. Closing for now.

Thanks for the detailed review, @yury-s - pushed a new commit (c09c9d63d) that addresses this directly:

• Reverted the previous change to the top-level/dependency classification predicate entirely, so buildProjectsClosure and the existing dependency-prepend step are back to exactly what they are on main - no conflation of structural role with filtering, no duplicated postShardTestFilters predicate logic.
• Added a separate, additive step that runs only when --last-failed (or another post-shard filter) is active: after the existing filtering and dependency-prepend logic finishes, any project that got excluded solely because it's someone else's dependency (and that someone didn't survive filtering) is checked for matching tests of its own. If found, it's added as an independent entry point, pulling in its own prerequisites in full via the same buildProjectsClosure mechanism.
• This means a dependency project that is needed by a surviving top-level project is completely unaffected by this change and still always runs in full, exactly as before - I added a dedicated regression test for that exact scenario to make sure.

Test results (npm run ttest -- runner.spec.ts -g "last.failed|last-failed|dependenc"):

  ok 1 should run last failed tests
  ok 2 should run last failed tests when the failing project is a dependency of another project
  ok 3 should run a dependency project in full when it is needed by a surviving top-level project under --last-failed   <- new regression test for the exact concern raised above
  ok 4 should run nothing with --last-failed when previous run had no failures
  ok 5 should run last failed tests in a shard
  ok 6 should run last failed tests in a shard with PLAYWRIGHT_LAST_RUN_OUTPUT_FILE
  ok 7 should run last failed tests in a shard with --last-failed-file

  7 passed (30.1s)

Also ran the full deps.spec.ts suite (26 tests) and runner.spec.ts in full (23 passed, 9 skipped by design) with no regressions.

I don't have permission to reopen this PR myself (looks like GitHub restricts that to whoever closed it) - happy to have it reopened for another look, or let me know if you'd like anything else adjusted.